前面我们可以使用synchronized关键字来实现线程之间的同步互斥,lock接口同样也是在JDK1.5中提出,同样是解决线程安全性问题的另一种解决方案,而且它更强大,更灵活本片博客介绍对其展开介绍;
Lock接口有如下几个实现类:
- ReentrantLock–JDK实现的锁
- ReentrantReadWritrLock.ReadLock
- ReentrantReadWriteLock.WriteLock
打个例子
1 | public class Demo01 { |
如上代码 i++ 被 Mylock.lock()和 Mylock.unlock()围住,显示的获取和释放锁,具有同步性…
其中,ReentrantLock一个可重入的互斥锁 Lock,它具有与使用 synchronized 方法和语句所访问的隐式监视器锁相同的一些基本行为和语义,但功能更强大。
Lock 与 Synchronized 相比较,显而易见的就是,Lock需要显示的去获取锁,释放锁,比较繁琐,但是繁琐带来了更大好处,让代码更灵活…Lock是对Synchronized的封装…
比如:
- 在控制锁的获取和释放,以及何时何地获取释放
- 使用Lock,可以很方便的实现锁的公平性ReentrantLock(boolean fair)
- 强大的API
- 非阻塞获取锁:tryLock()
- 可中断式获取线程acquireSharedInterruptibly(int arg)
- 超时获取线程tryAcquireSharedNanos(int arg , long nanosTimeout)
一 . Conditon&Reentrantlock
1. Condition实现正确的通知/等待
- 注意点,一定要在condition.wait()方法调用之前,使用lock.lock()方法获取对象同步锁,否则抛出异常
1 | public void waitMethod(){ |
运行结果:1
2Thread-0等待了...1549450097987
main被唤醒了...1549450099988
2 使用多个Condition实现,通知部分线程
接下来就是重头戏了Condition控制通知指定的线程醒来
1 | public void waitMethod(){ |
运行结果:1
2Thread-0等待了...1549450097987
main被唤醒了...1549450099988
2 使用多个Condition实现,通知部分线程
接下来就是重头戏了Condition控制通知指定的线程醒来
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
/*
* 使用多个Condition, 唤醒指定的线程
* */
public class demo2 {
private Lock lock = new ReentrantLock();
private Condition conditionA = lock.newCondition();
private Condition conditionB = lock.newCondition();
public void waitA(){
try{
lock.lock();
System.out.println(Thread.currentThread().getName()+"等待了..."+System.currentTimeMillis());
try {
conditionA.await();
System.out.println(Thread.currentThread().getName()+"await之后的代码..."+System.currentTimeMillis());
} catch (InterruptedException e) {
e.printStackTrace();
}
}finally {
lock.unlock();
}
}
public void waitB(){
try{
lock.lock();
System.out.println(Thread.currentThread().getName()+"等待了..."+System.currentTimeMillis());
try {
conditionB.await();
System.out.println(Thread.currentThread().getName()+"await之后的代码..."+System.currentTimeMillis());
} catch (InterruptedException e) {
e.printStackTrace();
}
}finally {
lock.unlock();
}
}
public void signalAALL(){
try{
lock.lock();
conditionA.signalAll();
System.out.println(Thread.currentThread().getName()+" 执行唤醒操作. ."+System.currentTimeMillis());
}finally {
lock.unlock();
}
}
public void signalBBLL(){
try{
lock.lock();
System.out.println(Thread.currentThread().getName()+" 被唤醒了.."+System.currentTimeMillis());
conditionB.signalAll();
}finally {
lock.unlock();
}
}
public static void main(String[] args) {
demo2 demo2 = new demo2();
ExecutorService executorService = Executors.newCachedThreadPool();
executorService.execute(new Runnable() {
public void run() {
demo2.waitA();
// demo2.waitB();
}
});
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
demo2.signalAALL();
System.out.println("mian 线程结束...");
}
}
结果:1
2
3
4pool-1-thread-1等待了...1549459953814
main 执行唤醒操作. .1549459955805
mian 线程结束...
pool-1-thread-1await之后的代码...1549459955805
- 通过结果可以看到,ReentrantLock对象,可以唤醒指定种类的线程,使用个Condition让线程等待,就用哪个Condition去把它唤醒
公平锁与非公平锁
Lock锁分为公平锁和非公平锁,所谓公平锁,就是表示线程获取锁的顺序,是按照线程加锁的顺序来实现的,也就是FIFO的顺序先进先出的顺序,而非公平锁描述的则是一种锁的随机抢占机制,还可能会导致一些线程根本抢不着锁而被饿死,结果就是不公平了
- ReentrantLock支持公平锁
ReentrantLock()
创建一个 ReentrantLock 的实例。
构造方法名 | 简介 |
---|---|
ReentrantLock(boolean fair) | 创建一个具有给定公平策略的 ReentrantLock。 |
ReentrantLock几组常用API
第一组:
方法名 | 作用
—|—
int getHoldCount() | 查询当前线程保存此锁的个数,(执行lock.lock()的次数),即重入的次数
int getQueueLength() | 返回正在等待获取此锁(调用该方法的锁)的线程的个数,比如有五条线程已经准备就绪了,其中一条线程首先执行lock.await()方法,紧接着调用该方法,获取到的返回值为4,说明有四条线程正在等待此lock
int getWaitQueueLength(Condition condition) | 返回正在等待和此锁相关的condition的线程数**
第二组:
方法名 | 作用
—|—
boolean hasQueuedThread(Thread thread) | 判断当前线程是否正在等到获取到此锁
boolean hasQueuedThreads() | 在所有的线程中查询,是否有线程正在等待此所的锁定
boolean hasWaiters(Condition condition) | 判断是否有线程正在等待和此condition相关的条件
第三组
方法名 | 作用 |
---|---|
boolean isFair() | 判断此锁是不是公平的 |
boolean isHeldByCurrentThread() | 判断当前线程是否拿到了锁 |
boolean isLocked() | 判断此锁是否由任意线程保持 |
第四组
lock()与lockInterruptibly()
假如出现下面几步,我们这两种加锁方法,会有什么反应?,第一: 线程A启动,使用lock()加锁,第二步: CPU的执行权被线程B抢到,且线程B使用interrupted()方法给线程A打上中断的标记..第三步: 线程A继续执行
- 使用lock()加锁,假如我们没有使用isInterrupted()判断的话,代码会按照原来的顺序依次全部执行,没有异常,线程AB正常结束
- 使用lockInterruptibly()加锁,线程A被中断后,会调用lockInterruptibly()报异常,进入catch代码块
tryLock()与Lock()
boolean tryLock()与void lock() 前者是有返回值的,两者都能去获取锁,而tryLock()直意尝试获取锁,有就拿,没有算了,它多了一步判断,它在调用时,会去判断此锁是否被其他线程锁定,如果没有,则获取,并返回ture
1 | if(lock.tryLock()){ |
可以看到,使用tryLock(),不至于当前线程被阻塞住
方法名 | 作用 |
---|---|
boolean tryLock(Long timeout,TimeUnit unit) | 如果在给定的等待时间内,锁没有被其他线程拿到,并且当前线程也没有被中断,获取锁 |
await()和awaitUninterrupted()
当线程A await() 线程B给线程A打上中断的标记
- 1.中断 2,抛出中断异常 3. 进入catch块
当线程A awaitUninterrupted() 线程B给线程A打上中断的标记
- 1.中断
boolean awaitUtil(Date deadLine);
出现一下几种情况,线程被唤醒
- 等待的时间结束
- 在等待.被中断的过程被提前唤醒
- 被中断
读写锁(排它锁,共享锁)
在一个不需要操作实例变量的方法中,完全可以使用读写锁来提升该方法的代码运行速度
- 读操作相关的锁是共享锁,写操作相关的锁为排他锁
ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
- 读读共享 lock.readLock().lock();
- 写写互斥 lock.writeLock().lock();
- 读写互斥
获取读写锁
1 | public void read() { |
创建四条线程测试
1 | 获取到了读锁Thread-0 1548851348805 |
JDK8新增StampedLock对ReentrantReadWriteLock进行增强
stamped:贴上邮票的; 盖上邮戳的,拿到锁之后会返回给我们一个票据,根据这个Stamp的值判断是在读的时候发生了写,还是在写的时候发生了读操作
解决的问题:
在高并发的情况下,读操作的次数远远大于写操作,,因为读写互斥,写操作可能就会出现饥饿的情况,一直抢占不到cpu的资源
解决方法:
当然可以使用公平的ReadWriteLock,但是依然有性能问题
StampedLock的乐观锁实现了读写共享提升了!
StampedLock里面有两种锁
乐观锁:
读锁并不会阻塞写锁
1 | public long tryOptimisticRead() {...} |
悲观锁:
读写互斥,和ReentrantReadWriteLock实现相同的功能
API:
独占的获取写锁,若锁被其他线程获取到,则阻塞,注意它是相对于ReentrantReadWriteLock来讲,它是有返回值的,返回值的作用:
- 释放锁(unlock的需要参数)
- 进行锁的转换
1 | /** |
1 |
|
乐观锁!!!它获取到的锁,读写锁非互斥
返回一个标记,这个标记过一会用去 校验, 如果锁是排它锁,返回零
1 |
|
校验,如果锁还没被任何线程获取,获取被持有当前stamp的线程获取返回true , 如果 stamp为0,返回false
1 | /** |
锁的释放
1 |
|
读,写 锁之间的转换1
2
3
4
5
6
7
8
9
10 public long tryConvertToWriteLock(long stamp) {
..}
public long tryConvertToWriteLock(long stamp) {
..}
//释放读锁
public void unlockRead(long stamp) {..}
//释放写锁
public void unlockWrite(long stamp) {..}
简单使用后
1 | /* |
最后提一下 > 如何选择大名鼎鼎的AQS最有名的实现类ReentrantLock和synchronized这个JVM提供的锁,一开始synchronized是一个笨重的重量级锁,但是jdk1.5之后,进行了偏向锁,轻量级锁的优化,使它的性能和ReentrantLock擦不多了,于是没有特殊的要求,官方推荐使用synchronized
什么情况下使用ReentrantLock呢?
- 使用它特有的公平锁
- 使用它的Condition类,分组唤醒指定的线程
- 提供了能够中断正在等待锁的线程的机制,lock.lockInterrupted()